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REMARKS/ARGUMENTS 

The Office Action mailed June 1, 2007 has been received and the Examiner's comments 
carefully reviewed. The Office Action rejected claims 1-20. Claims 1-15 and 17-19 were 
rejected under 35 U.S.C. 103(a) as being unpatentable over Klassen et al. (U.S. Patent No. 
6,71 1,137) (hereinafter "Klassen") in view of Dillon et al. (U.S. Patent No. 6,473,793) 
(hereinafter "Dillon"). Independent Claims 1, 7 and 1 1 have been amended. No new matter has 
been added. For at least the following reasons, Applicants respectfully submit that the presently 
pending claims are in condition for allowance. 

Claim Rejections 

With regard to Claim 1, the Office Action states that Dillon teaches "automatically tuning 
the size of the TCP receive window on the receiving computing device (hybrid gateway receives 
the packet and adjusting the window size based on the user bandwidth) based on the determined 
bandwidth, wherein automatically tuning the size of the TCP receive window comprises setting 
the size of the current TCP receive window without manual intervention and setting the size of 
the current TCP receive window sets the number of packets allowed to be sent from a sending 
computer device to the receiving computing device before an acknowledgment is sent from the 
receiving computing device to the sending computing device (figures 1 and 14; column 9 lines 
39-67; column 10 lines 12-43; column 11 lines23-35; column 12 lines 4-30; column 16 lines 8- 
36; column 18 lines 39-50; column 19, line 5 to column 20 line 40; column 21 lines 26-32; and 
column 22 lines 1-3)." The Applicants respectfully disagree but have amended the claims to 
more clearly define the invention. 

As amended, Claim 1 recites in part "automatically determining a bandwidth of a 
network connection of a receiving computing device on the receiving computing device; and 
automatically tuning the size of the TCP receive window on the receiving computing device 
based on the determined bandwidth; wherein the automatically tuning comprises setting the size 
of the current TCP recei ve window directly on the receiving computing device by the receiving 
computing device without manual intervention and wherein setting the size of the current TCP 
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receive window sets the number of packets allowed to be sent from a sending computer device to 
the receiving computing device before an acknowledgment is sent from the receiving computing 
device to the sending computing device; wherein setting the size of the TCP receive window 
includes setting a value that is stored on the receiving computing device that is referenced for 
each TCP connection setup; wherein the value setting the receiving computing device is different 
from a parameter within a TCP packet that indicates the size of the TCP receive window on the 
receiving computing device." Among other differences, Dillon teaches adjusting a packet that is 
meant for another machine to indicate the TCP window size and does not teach setting the size of 
the TCP window itself 

Dillon adjusts the throughput of a connection at a gateway device that is located between 
the source computer and the requesting terminal Dillon does not adjust the actual size of the 
TCP receive window. Instead, Dillon adjusts a value that is advertised as the window size by 
adjusting a parameter that is contained within each of the TCP packets that have already been 
sent by the source computer. At column 9, lines 39-47, Dillon states "When the hybrid gateway 
150 receives the packet, it strips off the tunneling header, revealing the true header with the 
application server 140 as the destination. The software within the hybrid gateway 150 identifies 
the packet sender using the source address in the true header. Based on the identity of the packet 
sender, their segmented level of service, and collected statistics regarding usage history, the 
advertized window size of the TCP packet is modified, if necessary, to throttle the user f s 
bandwidth." Nowhere does Dillon adjust a value that changes the size of the TCP receive 
window on the receiving computing device. Claim 1 clearly states that the TCP window size is 
set on the receiving computing device by the receiving computing device and is done by 
adjusting a value that is stored on the receiving computing device. Since the cited references do 
not teach setting the window size, or setting the window size on the receiving computing device, 
Claim 1 is proposed to be allowable. Claims 7 and 1 1 have been similarly amended, albeit 
differently. 

Claim 7 as amended recites in part "determining a network connection device on the 
receiving computing device; determining a throughput of the network connection device of the 
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receiving computing device; wherein the receiving computing device is a user device; 
determining a size to set the TCP receive window based on the determined throughput by 
accessing a data structure and extracting the size from the data structure based on the determined 
throughput; wherein the data structure is segmented based on bandwidth of a connection device; 
wherein the data structure includes at least three different sizes to set the TCP receive window; 
and wherein the data structure includes sizes to set the TCP receive window for at least three 
different operating system; automatically tuning the size of the TCP receive window directly on 
the receiving computing device by the receiving computing device based on the determined 
throughput of the connection by setting the size of the TCP receive window automatically 
without manual intervention and wherein setting the size of the TCP receive window sets the 
number of packets allowed to be sent from a sending computer device to the receiving 
computing device before an acknowledgment is sent from the receiving computing device to the 
sending computing device; wherein setting the size is performed by the receiving computing 
device and involves setting a value within a configuration database that is accessed by the 
operating system of the receiving computing device; wherein the value for the TCP receive 
window is referenced when a TCP connection is setup; wherein the value is different from a 
parameter within a TCP packet that indicates the size of the TCP receive window on the 
receiving computing device; and determining when the network connection has changed by 
monitoring a connection of network hardware that is associated with the network connection and 
when the network connection changes automatically tuning the size of the TCP receive window." 
Claim 7 is proposed to be allowable for at least the reasons presented above. Additionally, 
Claim 7 includes recitations that are not found in the other claims that is not taught or suggested 
by the cited references. For example, Claim 7 includes determining the network connection 
device of the receiving computing device and setting the size of the TCP receive window within 
a database that is accessed by the operating system when a TCP connection is setup. Claims 
depending from Claim 7 are proposed to be allowable since they depend from a valid base claim. 

Claim 1 1 as amended recites in part "setting the size of the receive window based on the 
determined bandwidth without manual intervention and wherein setting the size of the receive 
window sets the number of packets allowed to be sent from a sending computer device to the 
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apparatus before an acknowledgment is sent from the apparatus to the sending computing device; 
wherein setting the size is performed by the receiving computing device and involves adjusting a 
value that is maintained within a registry on the receiving computing device." Claim 1 1 is 
proposed to be allowable for at least the reasons presented above. Additionally, Claim 1 1 
includes a further limitation that sets the value of the TCP receive window within a registry of 
the receiving computing device that is not taught or suggested by the cited references. Claims 
depending from Claim 7 are proposed to be allowable since they depend from a valid base claim. 
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Conclusion 

In view of the foregoing remarks, all pending claims are believed to be allowable and the 
application is in condition for allowance. Therefore, a Notice of Allowance is respectfully 
requested. Should the Examiner have any further issues regarding this application, the Examiner 
is requested to contact the undersigned attorney for the applicant at the telephone number 
provided below. 



Respectfully submitted, 
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